Now that more and more people are jumping onto the Macromedia Flash application bandwagon I'm starting to see a growing number of questions about security and Macromedia Flash. In particular, developers are often unsure if Macromedia Flash applications can have the same level of security as a well-designed HTML-based application. The answer to that question is most definitely yes, if you design your application properly.

Of SWFs and ostriches
The first thing to understand about Macromedia Flash is that, from a security standpoint, it's no different from HTML and JavaScript - anyone can read the source. While SWFs aren't human readable like HTML and JavaScript, there are numerous tools out there for taking a SWF and extracting all of its assets, including ActionScript. Because of this fact you should never hard code sensitive data inside of your SWF; doing so would be the security equivalent of putting your head in the sand like an ostrich and assuming that because you can't see anyone, they can't see you.

You probably realize that this means that all of the data that your SWFs need must be retrieved from a server. Luckily you can use the exact same methods that standard web applications use to keep those data exchanges secure.

Macromedia Flash & SSL
The standard method for ensuring secure connections in web apps is to work from behind a special type of web server; a HTTPS server. This is just a standard HTTP server that has its communications encrypted with SSL (secure socket layer) technology.

When you use POST to send data from Macromedia Flash to the server, the Macromedia Flash plug-in utilizes the browsers POST capabilities rather than handling it directly. This is done so that if it happens that the SWF is communicating with a HTTPS server the data will be encrypted before it is sent. What this means to you, as a developer, is that you just need to take the same precautions with a potentially sensitive Macromedia Flash application as you would with a sensitive HTML app - place it on an HTTPS server. This way, not only will the data you send to the server stay secure, but also the little lock icon at the bottom of the browser will be locked, indicating to your users that your application is secure.

Crypto Hash Boulevard (It's one way)
Sometimes it's simply not possible to set up or get your hands on a HTTPS server. In those situations you can at least keep some of your data secure by using what is known as a cryptographic hash function. A crypto hash function is a function that given input produces a unique output that can not be used to determine the input value. That is to say, a crypto hash function is one way—you can get the output from the input but you can't determine the input just by looking at the output.

Crypto hash functions are useful when the user knows their password, and you have their password stored on the server, but you don't want to have to send the password as plain text across the Internet. The way you use a crypto hash function to do this is as follows:

1. First your SWF contacts the server and asks for a random string (let's call it S). Before the server sends S to your SWF it records its value.
2. The SWF then concatenates S with the password the user inputted and feeds the result through a crypto hash algorithm (let's call the result A).
3. Now the SWF sends A to the server. The server then finds the value for S that it sent to the SWF and concatenates it with the users password that it retrieves from the database. The server then runs the result through the same crypto hash function that the client used. (Let's call the result B).
4. Finally, if A and B match, the server knows that the password was correct. The actual password (or anything that could be used to find the password) was never sent across the net.

There are a number of these types of algorithms out there, but the two most popular are known as MD5 and SHA1 (catchy names, eh?). SHA1 is generally considered to be the more secure of the two, because its output is longer than that of MD5 (the longer the output the harder it is to try to crack). You can download an implementation of SHA1 for ActionScript from my personal website: http://www.waxpraxis.org/archives/000035.html.

Other security concerns
In addition to concerns about keeping Macromedia Flash's data secure, I have also seen a number of e-mail messages and posts worried about the new local file system, camera, and microphone capabilities of Macromedia Flash. The good news is that there is nothing to worry about (I've personally tried to break it many, many times and have yet to make a dent).

All of these features are secured per domain in a method that is even more secure than browser cookies! That is, the user has to set their options for who can use access their webcam and mic, as well as how much information can be stored on their hard drive on a per domain basis. One domain can not read information stored by another, period.

Also, in order to prevent cross-site attacks, a SWF is limited to loading data from the domain where the SWF itself is stored. A movie on www.macromedia.com can load information from foo.macromedia.com but not from www.nastyhackerperson.com.

Macromedia Flash and JS
One issue brought up recently has to do with the fact that Macromedia Flash can call JavaScript by using getURL like this:

getURL("javascript:alert('hello!')");

Because of this, any site that allows users to display their own SWFs is open to a having its users cookies stolen. The fact of the matter is that nothing should be allowed to be displayed on your site until it has been properly "sanitized", and yes, that does include SWFs (even ones that are just linked in).

Conclusion
Hopefully this article has given you a leg up in understanding how to work with Macromedia Flash securely. For more information on Macromedia Flash and security, make sure you read the Macromedia Flash Security white paper (498K in PDF format).